Knowledge systems are computer systems that emulate reasoning tasks by using an "inference engine" to interpret machine readable knowledge stored in a "knowledge base." Knowledge systems are becoming useful for problems that require diagnosis, recommendation, selection or classification. Such tasks have in the past been performed by human experts. It is becoming known that if the domain of the knowledge base, or scope of the problem, is sufficiently narrow and a sufficiently large body of knowledge is properly encoded in the knowledge base, then the knowledge system can achieve performance matching or exceeding the ability of a human expert. In such a case the knowledge system becomes an "expert system".
The first step in building a knowledge system involves encoding unstructured, often even unarticulated, knowledge into machine readable form. The encoding process is performed by a "knowledge engineer" who must be adept at both the milking of knowledge from conventional sources such as human experts and technical manuals, as well as the encoding of the knowledge into a machine readable knowledge system language. The ease of the encoding step is dependent on the particular syntax, intelligibility, and capabilities of the knowledge system language itself, as well as the availability of "knowledge engineering tools" used by the knowledge engineer to test, debug, augment and modify the knowledge base.
In particular, when designing a knowledge system in some application domain, the knowledge engineer works with a human expert to define the vocabulary and structure of the domain, the judgmental knowledge of the domain, and the method by which a user can access the knowledge in the knowledge base.
The vocabulary and structure of the domain must be defined both in general and with respect to the particular problem that the knowledge system will address. The vocabulary of the domain refers to the names of the individual objects and ideas that must be encoded in the knowledge base. The structure of the domain refers to relationships between the objects and the ideas in the domain. The judgmental knowledge of the domain refers to the rules of thumb or rules of inference which are used by a human expert to solve a problem involving uncertain knowledge or to restrict the scope of relevant knowledge or to direct the search for solutions among various possibilities covered by the knowledge base.
A user typically accesses knowledge in the knowledge system through a consultation. It is important that the consultation occurs in a manner that assures the user that the knowledge in the knowledge base is being properly considered and applied. It is particularly important, for example, that the user is not asked for redundant information and is given specific reasons why the knowledge system arrives at particular conclusions.
It is desirable that knowledge engineers have available to them high quality knowledge engineering tools since the purpose of a tool is to make a better product or knowledge system using less time and effort. In particular, the quality of the product is measured in terms of the reliability of the product, how easily the product can be maintained, and how easily the product can be extended to incorporate new features and additional knowledge.
In contrast to mechanical tools, a knowledge engineering tool is easily duplicated by copying. For this reason the knowledge engineering tool is typically used as a part of the final product or knowledge system. In such a case the performance and capabilities of the final product are dependent upon the performance and capabilities of the parts of the knowledge engineering tool which are incorporated into the knowledge system. For this purpose, the most important capability of the knowledge engineering tool is its ability to exercise control over the knowledge base. This degree of control is a measure of the range of inference strategies that are easily used by the inference engine. The knowledge engineering tool must also be capable of explicitly stating relevant knowledge in a machine readable form. This capability of the knowledge engineering tool to create a knowledge base effectively representing knowledge is known as declarative ability or range of propositional power.
The knowledge engineering tool includes a consultation driver portion which is usually incorporated into the knowledge system for conducting a consultation or question-and-answer session with the user. The consultation driver portion of the knowledge engineering tool is measured in a number of dimensions, including its interactive ability or ease of conducting a consultation, its justification or extent to which the system justifies its conclusions, its legibility or readability of the knowledge after any translation, and its judgmental capability in expressing uncertain knowledge and heuristic inferences. The consultation driver is also measured by its ability to offer help or guidance to the less experienced user.
Knowledge engineering tools have been available based on the EMYCIN tool developed from the Stanford University consultant program called MYCIN which diagnoses blood-born bacterial and meningitis infections and recommends appropriate therapy. As described in The Emycin Manual by Van Melle et al., Stanford University Report No. STAN-CS-81-885, Stanford CA 94305 (October, 1981) EMYCIN is a domain-independent system for constructing rule-based consultant expert system programs. Domain knowledge is represented in EMYCIN systems primarily as production rules, which are applied by a goal-directed backward-chaining control structure. Rules and consultation data are permitted to have associated measures of certainty, and incomplete data entry is allowed. The EMYCIN system includes an explanation facility displaying the line of reasoning followed by the consultation program, and answers questions from the client about the content of its knowledge base. To aid the system designer in producing a knowledge base for a domain, EMYCIN provides a terse and stylized language for writing rules; extensive checks to catch common user errors, such as misspellings; and methods for handling all necessary indexing chores.
The EMYCIN vocabulary of the domain defines a context-parameter-value triple as the elemental representation of an object or an idea. In particular, the context refers generally to instances of an object type, a parameter refers to an attribute of the object, and the value refers to the particular value of a parameter for a particular context instance. The domain is structured in terms of a hierarchy of context types called the "context tree." The context tree is defined by parent and offspring declarations for the context types and the instantiation of contexts is similar to the invocation of a subroutine for each context, the subroutine in effect being defined by various declarations in the context definition. A consultation is started by instantiating a root context and the branches from this root context define major steps in the consultation during which the offspring contexts of the root node are instantiated. Thus, the context definitions are used to structure the data or evidence required to advise the client about the root context. In the MYCIN medical diagnosis system, for example, the root context is called the "PATIENT" and the offspring of the root context are various types of cultures describing diagnostic tests that the doctor performs to isolate the organisms causing an infection in the patient.
Besides consultation control, the context tree is used to organize the distinguished components of some object. Similarly, the context tree is useful for representing distinguished events or situations that happened to an object.
Although the context tree is used for control purposes, the judgmental rules in EMYCIN are also used for controlling the order in which tasks are performed. In addition to performing reasoning processes, the rules in EMYCIN classify case data in a symbolic fashion.
It has been recognized that EMYCIN has substantial limitations in its ability to emulate a human expert. In the field of medical diagnosis, Stanford researchers found that MYCIN was not especially suited to teaching medical diagnosis strategies since the method by which EMYCIN represented inference strategies and knowledge about infectious diseases was not well-suited for testing hypotheses. In response to this, the Stanford researchers developed an expert system called NEOMYCIN in which the hypothesis-testing strategy of medical diagnosis was structured in terms of tasks. Each task corresponded to a higher level goal invoking higher level rules stating methods for achieving the higher level goals.
The NEOMYCIN domain rules included four particular kinds of domain rules. These kinds of domain rules were base-level causal rules, trigger rules for directing attention to specific causes, data/hypothesis rules that associated data with particular hypotheses only when sufficient circumstantial data accummulated, and screening rules which put restrictions on data.
The Stanford researchers claimed to have learned several lessons through the development of NEOMYCIN. For a program to articulate general principles, it was concluded that strategy should be represented explicitly and abstractly. Strategies should be made explicit by means of a representation in which the control knowledge is explicit and is not imbedded or implicit in the domain knowledge, such as in rule clause ordering. Strategies should be made abstract by making meta-facts and tasks domain-independent. Also, if control is to be assumed by the tasks and meta-facts, then all control must be encoded in that way, because implicit actions in functions or hidden chaining in domain level rules lead to situations which do not fit into the overall task structure and cannot be adequately explained.
From these conclusions based on NEOMYCIN development, the Stanford researchers hypothesized general statements about advantages of abstract control knowledge in expert system design. Representing control knowledge abstractly, separately from domain facts and relations, was said to make the design more transparent and explainable. A body of abstract control knowledge was said to provide a generic framework for constructing knowledge bases for related problems in other domains and also provide a useful starting point for studying the nature of strategy. Moreover, it was said that an important design principle for building expert systems is to represent all control knowledge abstractly, separate from the domain knowledge it operates upon. In this respect, the control knowledge specifies when and how a program is to carry out its operations, such as pursuing a goal, focusing, acquiring data, and making inferences. See, for example, William J. Clancey, "The Advantages Of Abstract Control Knowledge In Expert System Design," Heuristic Programming Project, Computer Science Department, Stanford University, Stanford, CA 94305, Report No. HPP-83-17, March, 1983.